Microsoft Dynamic AX 2009 : The Batch Framework (part 2) - Batch-Enabling a Class

3. Batch-Enabling a Class

Each batch task is a batch-enabled class, and a class must be enabled for batch processing before it can be scheduled for execution as a batch task. The classes used for batch tasks are designated to run on either the client or the server. Tasks that run on the server can run automatically as part of a batch job, regardless of whether a client is open. Tasks that run on the client, however, must be run manually via the Batch processing form, which is in the Dynamics AX basic module, at Periodic\Batch\Processing.

Many classes included with Dynamics AX 2009 are already enabled for batch processing. You can also design a class that you create for execution within the Batch framework, as shown in the following example.

To allow your class to run as a batch task, you have to extend it from the RunBaseBatch class.

public class ExampleBatchTask extends RunBaseBatch

The RunBaseBatch class itself is an extension of the RunBase framework, so your batch class must adhere to the patterns and guidelines of the RunBase-extended classes.

To convert a class so that it’s batchable, you need to use the pack-unpack pattern and implement the methods pack and unpack to allow a class to be serialized. When a batch task gets created, its member variables are saved in a container using the pack method and stored in the Batch table. Later, when the batch server picks up the task for execution, it restores class member variables from the container using the unpack method, so it’s important to provide a correct list of variables necessary for class execution. If any member variable isn’t packable, the class can’t be packed and reinstantiated to the same state.

Following is an example of the pack and unpack methods.

public container pack()
{
    return [#CurrentVersion,#CurrentList];
}

public boolean unpack(container packedClass)
{
    Version version     = RunBase::getVersion(packedClass);
    switch (version)
    {
        case #CurrentVersion:
            [version,#CurrentList] = packedClass;
            break;
        default:
            return false;
    }
    return true;
}

The macros #CurrentList and #CurrentVersion referenced in the preceding code must be defined in the class declaration. #CurrentList is a macro holding a list of the class member variables to pack, as shown here.

   #define.CurrentVersion(1)
   #localmacro.CurrentList
        methodVariable1,
    methodVariable2
   #endmacro

You must implement the core logic of your batch class in the run method. If your batch class is designed to be executed on the server, there are some limitations on the operations you can use in the run method. For example, you can’t call any client logic or dialogs. However, you can still use Infolog classes—all Infolog and exception error messages are captured during batch class execution and stored in the Batch table.

You can also implement some RunBaseBatch-specific methods in your class to control its behavior as a batch task:

• runsImpersonated Determines whether the batch task is run on the server or on a client. The base method always returns true, which means that the batch must run under the authority of the person who scheduled the batch and that no client session is involved.

  Note

  You can also verify whether a batch task runs on an AOS or client by selecting the Run Location field in the Batch Tasks form. It’s a good idea to write your batch job to be executed on a server to take advantage of the Dynamics AX 2009 batch features for servers.

  
  

• canGoBatchJournal Determines whether the batch task class appears in the list of available classes when you create a new batch task using the Batch task form.